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1. INTRODUCTION 

Recently, robots made by integrating complex and diverse mechanical devices and sensors have 
been used in many applications. Robots are finding active use in various fields, from the existing 
manufacturing industry to the service sector [1]. In these areas, use cases are increasing in applications that 
involve working with humans or sharing tasks closely with them, such as serving and delivery [2], [3]. 

Service robots must work with humans or interact with customers to provide services [4], [5]. The 
development cost and duration of a service robot have increased considerably because it is difficult to apply 
the existing service robot architecture to these types due to the direction of design and development efforts 
depending on the purpose of the service. To this end, the demand for robot software frameworks such as 
robot operating system (ROS) [6] and OROCOS [7] has been constantly increasing. In particular, ROS1 has 
become the new norm for robotic developers, and existing robotic platforms offer integration to ROS1. 
However, ROS1 does not support real-time systems and communication protocols, which are the 
requirements for a reliable and deterministic robotic system. Thus, ROS2 [8] has been developed to solve 
these issues. ROS2 uses data distribution service (DDS) [9], [10] with the quality of service (QoS) concept to 
provide improve the real-time performance of inter-node communications and its security. However, robotic 
applications must perform multiple tasks that often involve multi-threading and multi-processing 
applications. ROS2 still lacks task management, which is essential for practical applications. Moreover, the 
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integration of new devices into ROS2 requires additional development effort to create specific drivers for 
specific devices. 

To address this issue, this paper proposes a scalable, flexible software architecture based on ROS2 
for service robots. The proposed software architecture is designed to be applicable to various robots. It uses a 
multiprocessing architecture and python and is designed to facilitate hardware deployment, software service 
expansion, and device integration. It is also designed to enable easier integration by inheriting the class when 
implementing the services of other functions through its use of multi-process classes. 

The SeoulTech service robot (SSR), a service robot with various sensors and actuators, was 
developed to apply the proposed software and verify the flexibility and scalability of the proposed software 
architecture. In addition, two Jetson Xavier NX boards were used as the control board and application board 
on which to deploy the applications and user interfaces so as to expand the artificial intelligence services 
offered by the robot. In addition, commercialized Kobuki2 [11] and StellarB2 [12] devices were utilized to 
verify the scalability of the application services. The application was developed to emulate a delivery 
scenario, on which the robot is expected to avoid three-dimensional obstacles while implementing various 
artificial intelligence features, such as text-to-speech (TTS) [13]. 

The contribution of the paper is the proposal of a scalable and flexible software architecture for 
service robots based on ROS2. The architecture is designed to ease hardware deployment, software service 
expansion, and device integration, making it applicable to a variety of robots. The authors also demonstrate 
the feasibility and scalability of the proposed architecture through the development of the SSR and its 
applications in a delivery scenario. In the future, the proposed architecture will implement floor obstacle 
avoidance and various artificial intelligence applications [14]-[16] as part of the continuing research on 
service robots applications that support more diverse scenarios. In addition, we will extend the software 
architecture to real-time systems by applying various forms of RTOS, such as RT-preempt [17] and Xenomai 
[18], [19], which are real-time systems, and by applying RT-AIDE [20] to interlock with non-real-time tasks. 


2. SOFTWARE DESIGN 

This section describes the design of the proposed software architecture. The design of a software 
architecture is the most crucial phase in the software development process. Therefore, the following 
considerations are taken into account when designing software architectures: i) scalable to and accessible by 
other software; ii) each device runs in its own context; iii) synchronization between processes/threads; 
iv) easy integration of multiple devices; and v) monitor process/thread activity. 


2.1. Scalable to and accessible by other software 

Service robots use various devices, such as cameras, microphones, and sensors, depending on the 
service purpose of the robot. For simple integration of these devices, each is modularized so that the software 
architecture can be designed in a platform format. In such cases, when developing a robot intended to provide 
a new service, it is easy to apply an existing robot software platform, and doing so has the advantage of 
reducing the development cost and duration. 

Here, we design the software architecture using python to simplify the issues of scaling and access 
to other software. Development in python is fast and it offers concise and easy grammar with high scalability 
and portability [21], [22]. The software architecture in this case is difficult to implement in a language such 
as C/C++, which is more commonly used, as complex operations and algorithms must be applied to 
implement the artificial intelligence required for service robots. In general, python make development easy 
due to the existence of numerous artificial intelligence libraries, including PyTorch [23] and TensorFlow [24]. 


2.2. Each device runs in its own context 

The features of the software are designed to run modules for each device in their own context. In 
general types of software architecture, multiple tasks are designed to be performed via multi-threading. 
However, python uses what is termed the global interrupt lock (GIL) [25] concept to avoid a deadlock 
between multiple threads. With GIL, only one thread runs per process. For this reason, in python, a single 
thread is capable of higher performance than a multi-thread setup, especially in CPU-bound threads. The 
software architecture developed to solve these problems is designed using the multi-processing technique. 


2.3. Synchronization between processes/threads 

Figure | shows the designed software architecture. The software architecture is designed with two 
main components: ControlCore and MainWindow. ControlCore is the main controller that deals with 
devices, interfaces, and the control software. MainWindow is a graphic user interface (GUI) that deals with 
signals and slots in the user interface. All objects and methods related to the robot control system are 


Bulletin of Electr Eng & Inf, Vol. 12, No. 5, October 2023: 3027-3038 


Bulletin of Electr Eng & Inf ISSN: 2302-9285 O 3029 


separated from the GUI. Data exchange capabilities between MainWindow and ControlCore are 
implemented using a callback function. The architecture is also applicable to a range of service robots, such 
as StellaB2, Kobuki2, and SSR. Multiple threads do not require special techniques for communication 
because each thread shares data with the others. However, for multiprocessing, a communication IPC 
between processors is required for data exchanges among the processes. 


Mobile_robot_ctrl Process 


External_comm Process 


CExternalComm 


- _server: EmbdTcpServer 


- serial : CserialPort Main Process 


- weight, payload, pose Queue 


command 


- robot physical limits, driveType + start_server(port, address ) 


_dockSystemLog : DockSystemLog 


+ deserialize_packet() + disconnect_client (port) 
T kProcMonitor : DockProcessMoni i 
+ parse_packet_values(payload) _dockProcMonitor : DockProcessMonitor + deserialize packet() 


| dockServerConnect : DockServerConnect Pipe 

| dockKobuki2 : DockKobuki2 command 
Queue | dockStellaB2 : DockStellaB2 
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+ connect(port) + send_packet(cmd, payload) 
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Ros_Nav_Node Process 


CROSLaunch 
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+ proc_send_command(cmd , value) 
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Pipe Queue 
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Ros_velpub_node Process 


CROSVelPub 
- topic_tf, odom, cmd_vel - cmd_vel 
- Qos - Qos 


+ start_timer(fperiod) 


+ start_timer(fperiod) 


+ update_odom_and_tf(x, y, theta, vel, omega ) +add_vel_cmd( vel_cmd) 
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Figure 1. Process diagram for software architecture 


Therefore, we design the communication architecture in the manner shown in Figure 2. In the 
design, interprocess communication is facilitated using pipes and queues. As shown in the figure, 
communication between the main process and another process is designed to communicate on a 1:1 basis 
using pipes. Reliable data delivery is possible by using pipes in this way. For communication from a process to the 
main process, N:N communication using a queue is utilized. The queue is designed to be scalable, allowing data to be 
exchanged and processed among multiple processes. The block option in Queue.get() is set to block until a message 
from a queue arrives, at which point it is set to pipe.poll(none) to prevent unnecessary CPU usage. The next step is to 
wait for a pipe without a time limit and no immediate return. In this way, unnecessary CPU usage is prevented. 


2.4. Easy integration of multiple devices 

This software architecture also provides classes of features for various devices. These classes consist 
of the functions used by each device, in which only protocol changes for the device can be used for other 
devices. Providing these classes will help developers create applications that are easier to integrate with 
various devices and will facilitate various services. Below the method used to implement these classes is 
described. ControlCore in Figure 1 essentially implements the MultiProcessBase class, which is the basis for 
implementing multiple processes. 
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Figure 3 shows the configuration of the MultiProcessBase class. In MultiProcessBase, mpDesc 
manages instances of the class. Queue sends feedback to ControlCore, which is the main process, and pipe 
receives commands from the main process. Each queue is periodically read within the thread and data is 
transferred to the main process. Because other processes are implemented by referring to this, if there is a 
function to be added, this class can be inherited and easily integrated. The following chart shows the 
processes currently being constructed. 


Main Process 


"NAME" Process 
E EEEE | "NAME" Process | 


- proc"NAME" : multiprocessing.Process Initailiztion 
- queue"NAME" : multiprocessing.Queue 
- pipe"NAME" : multiprocessing.PipeConnectior 


- thread"NAME" : multiprocessing.Queue 


thread" NAME" Queue 


command pipe.poll() 


Pipe Get command and 
value 
command 


and value 
Pipe.put() 


queue.put() 


Figure 2. Software communication architecture 


C] Native Python 
objects 


CMultiProcessBase 


- mpDesc : multiprocessing.Process 


- queue : multiprocessing.Queue 

- pipe : multiprocessing.Pipe 

- proc() : function 

- threadQueueBcast : threading. Thread 

- threadQueueBcastBk : threading. Thread 


Figure 3. MultiProcessBase class 


Here, CMobileRobotCtrl refers to the class of controlling mobile robots, creating robot objects, 
connecting the robot to the communication interface, and controlling the robot according to the data (motor 
encoder). Figure 4 shows the configuration of the mobile robot class. As shown in the figure, the class 
CMMobileRobot is a basic class that supports various types of mobile robots. Depending on DriveType, 
there are common features for several types of robots. CTMRDiff is the basic class of two-wheeled differential 
drive mobile robots (TWR), referring to a two-wheel differential robot that inherits CMobileRobot. A method 
for calculating common inverse kinematics and forward kinematics for all TMRs is provided. Currently, it 
provides a communication interface and information for Kobuki, SSR, and StellaB2. CKobuki2, CSSR, and 
CStellaB2 are classes that inherit CTMRDiff and process the actual information of each mobile robot. 
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The serial interface of the mobile robot is provided through the SerialPort class. Figure 5 shows the 
configuration of CserialPort. CserialPort is a class that provides a serial interface. It uses pyserial and 
implements it as a separate thread for recv, send, and recvqueue. The queue is utilized between read, recv and 
recvqueue threads to prevent data losses. 

CROSRobotNode is the class of creating a ROS2 RobotNode that publishes or subscribes to ROS 
topics such as odom, tf, and cmd_vel, among others. Figure 6 shows the configuration of the 
CROSNodeBase class. CROSNodeBase is a basic class that supports basic ROS nodes. The node name, 
topic, period, Qos, and other parameters can be set. CROSNodeRobot is a class that inherits CROS NodeBase 
to generate nodes for robots. Basically, mobile robots publish odom and tf pertaining to the robot's status and 
subscribe speed. CROSNodeVelPub is the class that publish cmd_vel and is used to test robots. 
CROSNodeVelPub is a class that inherits CROSNodeBase. 

CROSLaunch is the class that executes the any package, which receives the launch descriptor and 
executes the launch file. Figure 7 shows the configuration of the CROSLaunch class. CROSLaunch receives the 
package name and path to the launch file, receives the launch descriptor, and executes the launch file as a process. 
CExternalComm is the class related to external communication, and the more TCP communication is used, 
the more client connections and servers are generated. Figure 8 shows the configuration of the 
CExternalComm. CExternalComm generates a server through a socket. 


CMobileRebot 


- Robot physical limits, DriveType 
- Weight, Payload, Pose 


+ cale_pose(jointSpace Vel) 
+cale_joint_space(centerVel, angVel) 


CTMRDiff 
- DriveType= DIFFERENTIAL 
- nNoOfWheel=2 


> 


- serial : CserialPort - _serial : CserialPort -_ serial : CserialPort 
- Weight, Payload, Pose - Weight, Payload, Pose - Weight, Payload, Pose 
- Robot info, DriveType - Robot info, DriveType - Robot info, DriveType 


+ deserialize_packet() + deserialize_packet() + deserialize_packet() 

+ parse_packet_values(payload) | |+ parse_packet_values(payload) | |+ parse_packet_values(payload) 
+ connect(port) + connect(port) + connect(port) 

+ disconnect() + disconnect() + disconnect() 


Figure 4. Mobile robot class 


z Native Python 


objects 


- _serial : serial.Serial() 


- threadRecv : threading. Thread() 


- threadRecvQueue : threading. Thread() 
+ connect(port, baud) 

+ sendMsg(msg: bytearray) 

+ disconnect() 


Figure 5. CserialPort class 
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CROSNodeBase 


- NodeName, TopicName 
- fperiod, Qos 
A 


- topic_tf , odom, cmd_vel 

- Qos - Qos 

+ start_timer(fperiod) + start_timer(fperiod) 

+add_vel_cmd( vel_cmd) +update_odom_and _tf(x, y, theta, vel , omega ) 
+ clear_vel_cmd() 


CROSVelPub 


-cmd_vel 


Figure 6. ROSNodeBase class 


Native Python 
objects 
CROSLaunch 


-_launchPath : ament_index_python.packages 


- launchDes : multiprocessing.Process 


+ launch() 
+ terminate() 


Figure 7. ROSLaunch class 


CExternalComm 
- _server: EmbdTcpServer 
+ start_server(port, address ) 
+ stop_server() 
+ disconnect_client (port) 
+ deserialize_packet() 
+ parse_packet_values(adtData) 
+ make_packet(cmd, adtData) 


+ send_packet(cmd, payload) 


Figure 8. ExternalComm class 


2.5. Monitor process/thread activity 

The main window is largely divided into three parts. The first of there is the GUI for external 
communication. The GUI can check the server address or the client list. The second part is the GUI for the 
robots. This part allows each robot to communicate, or it provides a speed command to the robot and checks 
the encoder or the speed. The last part is a GUI that can show a list of threads or processes currently running 
and can check for communication errors or system errors. It is built in the form of a GUI multiple-document 
interface (GUI MDI) to make it easy to integrate multiple windows. 


3. IMPLEMENTATION OF A SSR ROBOT WITH ITS SOFTWARE ARCHITECTURE 

The validity of the designed software was applied to the newly implemented SSR robot. The SSR's 
main control unit was implemented on the Jetson Xavier NX board. In addition, the most basic navigation of 
the service robot is implemented through ROS2 Navigation2 to avoid 3D obstacles. 
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3.1. SSR robot 

Robots that apply software are as follows. The SSR is a service robot that developed sensor 
interface of drive unit and consist of a control board and an app board. For the servo controllers for driving 
wheels, STM32 is used. It communicates with the motor driver using RS485 communication. For the control 
boards and app boards, Jetson Xavier NX is used, and the LiDAR and camera required for navigation is 
connected to the control board. Figure 9 shows the SSR robot. The robot is constructed using the RealSense 
D435i as the camera, and LIDAR is operated by Hukoyo's URG-04LX-UGO1. Table 1 briefly describes the 
information about the robot by presenting its specifications. 


URG-04LX-UGO01 


Figure 9. Image of the SSR 


Table 1. SSR specifications 


Item Value 
Motor driver 10 
Wheel radius 15 
Number of casters 4 
Battery TABOS X2 
LiDAR URG-04LX-UGO1 
Camera RealSense D435i 
Payload 100 kg 
Velocity 0.3~2 m/s 


3.2. Implementation of service application 

Regarding the use of the Jetson Xavier NX boards, the system is constructed using JetPack 4.6 
provided by NVIDIA. The file system uses Ubuntu 18.04, and in this study, we use the ROS 2.0 Eloquent 
version, which is supported by the file system and satisfies the time constraints, to use the corresponding 
navigation stack. Table 2 shows the architecture of the system software configured on the Jetson Xavier NX 
board. 


Table 2. System software architecture 


Item Value 
Board Jetson Xavier NX 
OS Ubuntu 18.04 
ROS2 Eloquent 
Kernel 4.9.253-tegra 


Figure 10 shows the software deployment diagram of experiment. On the control board, the main 
process, MobileRobotCtrl process, ExternalComm process, ROSNavNode process, ROSRealsenseNode 
process, ROSRobotNode process, and the ROS2 processes are implemented. The app board implements 
artificial intelligence applications, in this case TTS, demo GUI. On the app, the main process, texttospeech 
process are implemented. The app board provide demo GUI. The control board and the app board use the 
TCP protocol provided by ExternalComm process. Therefore, the deployment of processes can be flexibly 
implemented with respect to hardware. 
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APP board 


P EPTOTERE 


 dockDemo : DemoGUI 


- listClients : list[SocketClient] 
- isTep : bool 


= 


Control board 
External_comm Process 


| dockSystemLog : DockSystemLog 

| dockProcMonitor : DockProcessMonitor 
| dockServerConnect : DockServerConnect 
| dockKobuki2 : DockKobuki2 

| dockStellaB2 : DockStellaB2 

| dockSSR : DockSSR H 


i procKobuki2 : mpKobuki2 m h Hiii 


- procStellaB2 : mpStellaB2 


prenas 
- procExternalComm : mpExternalComm Ros_Navigation Process - Controll server 


- procROSRobotNode : mpROSRobotNode - Bt_navigatior 
- procROSNavNode : mpROSNavigation - Navigation launch - Planner_server 
- procROSRealsenseNode : mpROSRealsense - Recovery_server 


- procROSRealsenseNode : mpROSRealsense ed - Local_costmap 
- Global_costmap 


- threadRead: threading. Thread 


- ser_port: pyserial.Serial Ros tóbot node Procési 
- threadWrite: threading.Thread = = 


- ROS Publish TF 
- topic_tf , odom, cmd _vel - ROS Publish Odometry 
Qos - ROS Subscribe CmdVel 


- threadStatus: theading. Thread 


Figure 10. Deployment diagram of service application 


Figure 11 shows the results of process monitoring. ROS2 does not offer these services. These 
services will help analyze and optimize the load of each application. In the software placement diagram 
shown in Figure 10, information about each process, such as the PID, status, CPU share, and behavioral CPU 
of the process being implemented, can be checked through the monitor. The CPU share shows the share for 
each core. In the figure, the ROS robot navigation node runs as a process the procROSRealsense Node, the 
ROS RobotRealsense node runs as the procROSNavNode, and it runs the python launch file, when the 
process of Nav2 or RealSense in ROS2 runs, the state enters a sleeping state and occupies 0% of the CPU. 
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Process Monitor ok 
PID STATUS CPU% CPU# NICE #ofThreads CTX-V CTX- CREATE TIME = 
MAIN 24418 running 59.8 4 i) 23 9428 31256 2022-06-28 12:01:13 
ExaRobot 24422 sleeping 17.8 1 0 5 26 28 2022-06-28 12:01:16 
Externalcomm 24424 sleeping 0.0 1 0 1 4 1 2022-06-28 12:01:16 
ROS Robot Node 24426 sleeping 29.3 3 0 7 6347 1406 2022-06-28 12:01:16 
ROS Robot Navigation 24428 sleeping 0.0 4 i?) 2 16 386 2022-06-28 12:01:16 
ROS Robot Realsense 24430 sleeping 0.0 o 0 2 15 447 2022-06-28 12:01:16 
realsense2_camera_node 24479 sleeping 99.8 3 0 18 93 222 2022-06-28 12:02:14 
static_transform_publisher | 24509 sleeping 0.0 2 0 7 74 96 2022-06-28 12:02:15 
urg_node_driver 24508 sleeping 0.0 2 0 9 169 208 2022-06-28 12:02:15 
cartographer_node 24510 running 29.9 S i?) 35 5189 74486 2022-06-28 12:02:15 
occupancy _grid_node 24512 sleeping 0.0 3 0 z 530 796 2022-06-28 12:02:15 
velocity_smoother 24524 sleeping 9.7 5 te) 7 5683 1188 2022-06-28 12:02:15 
controller_server 24525 sleeping 109.7 4 0 37 4293 1902 2022-06-28 12:02:15 
planner_server 24526 sleeping 79.8 4 0 37 366 1570 2022-06-28 12:02:15 
recoveries_server 24534 sleeping 10.0 2 [0] 19 1098 1426 2022-06-28 12:02:15 > 
4 r . > 
@ REFRESH v| AUTO 100 > [ms] 


Figure 11. Process monitoring results of experiment 


3.3. Autonomous navigation 

A basic function of a service robot is navigation, which is an autonomous driving function that 
allows the robot to move safely to the desired point while avoiding obstacles. In ROS2, by providing a 
navigation stack as a package, navigation can be implemented with the package provided without the need to 
implement the algorithm directly [26]. The package used to implement the ROS2 navigation stack is as 
follows: i) DWB_controller; ii) navfn_planner; iii) local_costmap; iv) global_costmap; v) recoveries; and 
vi) bt_navigator. 

DWB. controllers correspond to local_planners and are commonly used to create paths to avoid 
obstacles around a robot. During ROS2 navigation, dwb_controller is used as the default controller. 
Navfn_planner corresponds to global_planner and generates a path from the start point of the robot to the 
destination. Local_costmap is a map used by dwb_controller to search for obstacles that are detected 
dynamically around the robot. Global_costmap is a map used in navfn_planner to create a route to a 
destination by avoiding static obstacles. Recovery means waiting until a costmap or obstacle disappears such 
that if a problem occurs during the operation of the navigation stack, the problem can be resolved. In this 
study, the point cloud of the camera was used using spatio-temporal voxel layer (STVL) to avoid 3D 
obstacles, and autonomous navigation was implemented to avoid 3D obstacles [27]. 


4. EXPERIMENTAL RESULTS AND VALIDATION 

Autonomous navigation was performed in the 3D obstacle environment of the service robot using 
SSR, a robot to which the developed software architecture was applied. The space for the experiment used a 
space containing 3D obstacles such as a table, which 2D LiDAR cannot detect. Figure 12 shows the actual 
experimental indoor environment used for the experiment here. The moving point has starting position ©) 
and target points labeled as (1), @) and G). The experimental environment was taken at the point indicated 
on the map. 

The experiment involves transferring the location of each target point to the robot through TCP 
communication so that the robot can autonomously drive to that point while avoiding obstacles. When 
moving to the target point, TTS is used to signify the arrival of the robot at the target point. Figure 13 shows 
two Rviz images and the actual scenario during autonomous driving. The figure was taken when the robot 
drives toward points (1) to (2). The left Rviz image is a costmap indicated by circles using only the LIDAR 
device. In the image, the table can’t be detected. In the real-world image, there is a table in front of the robot. 
As indicated by the right Rviz image, the table recognized by the camera is expressed in voxels and the 
obstacle is avoided by using it in the costmap. Figure 14 shows the navigation driving path of the robot in the 
experiment while avoiding 2D and 3D obstacles. In a three-dimensional environment, it is possible to create 
voxels with a camera and apply them to a costmap to confirm that the robot will move to the desired point 
without a collision with the table. 
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Ca: 


Figure 13. Navigation driving 


Figure 14. Autonomous navigation result while avoiding 2D and 3D obstacles 


5. CONCLUSION 

In this paper, we construct ROS2-based scalable software architecture for service robots and 
designed an inter-process communication methodology. For flexibility during development efforts, the 
software architecture is designed as a scalable type of architecture that can be applied to various robots, 
instilling the advantage of reducing the development period and development cost during the development of 
a new robot while also allowing easy integration of various devices. It is possible to scale easily by adding 
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multiple other processes using the class. The proposed architecture was verified by applying it to SSR, a 
Jetson Xavier NX-based service robot. We implemented three-dimensional obstacle avoidance autonomous 
driving, which is a basic function of a service robot, and verified that the proposed architecture is useful as a 
form of service robot software architecture by applying it to various robots. 
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